home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 385 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  5.6 KB

  1. From: "Eugene Lazutkin" <INT@msn.com>
  2. Message-ID: <UPMAIL04.199602192354270852@msn.com>
  3. X-Original-Date: Mon, 19 Feb 96 23:48:22 UT
  4. Path: in2.uu.net!bounce-back
  5. Date: 20 Feb 96 07:20:29 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Organization: -
  8. Newsgroups: comp.std.c++
  9. Subject: RE:  Portability. Modules. WAS: RE:  Are all Windows programs 
  10.     ill-formed?
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMSl2ieEDnX0m9pzZAQHsSgF9F9s0YCtd431gZz2Zr+fHgV8bXuQmgOhH
  13.     Qh+TaR8I18R5tj9aa/y99nvpmUoDyoPG
  14.     =LUzt
  15.  
  16. On     Tuesday, February 13, 1996 9:51 AM,     JdeBP@jba.co.uk 
  17.     (Jonathan de Boyne Pollard) wrote:
  18. > Eugene Lazutkin (eugene@int.com) wrote:
  19. > | On     Tuesday, February 06, 1996 9:18 PM, 
  20. > | About the main() function.  A Windows compiler (MS, Borland, Symantec,
  21. > | Watcom) doesn't check its presence. Linker does. It knows the name of
  22. > | an entry point.
  23. > Not entirely correct.  One of the compilers that you mention (Borland)
  24. > emits additional code when it encounters the definition of `main'.  See
  25. > Borland's library source for details.
  26. > |          You may think that main() is buried in the standard Windows
  27. > | library and it will call WinMain(). That's it, you use the main()
  28. > | implicitly.
  29. > Again, this is not in fact true, and part of the problem that the original
  30. > poster was pointing out.  The startup code in most Windows compilers calls
  31. > WinMain directly.  There is no `main' function anywhere in the program at
  32. > all.
  33.  
  34. I don't care about the actual implementation.  Virtually there is a main().
  35. I know that all my static constructors will be executed BEFORE main(), 
  36. WinMain() or any other head procedure.  It is important.  It doesn't make 
  37. any difference for me whether or not main() is the first called subroutine.
  38. In fact, in most cases it is not true.  Almost all platforms call some
  39. stub before your main().
  40.  
  41. > | BTW, the same can be applied to the Unix (MacOS) platform.  X-based
  42. > | (Motif-based, Fresco-based,...) program are not portable either unless
  43. > | you have the specific GUI implementation for your target platforms.
  44. > Not so.  If we are expanding the discussion to other platforms, you will
  45. > find that many other platforms do not demand that programs be ill-formed 
  46. > (as a program lacking any definition of `main' surely is).
  47.  
  48. You can call a main() from the WinMain(). You can put this stub into your 
  49. default library.  You can ask Bill Gates to do that for all VC++ customers.  
  50. Does it make anybody happy? I don't think so.  (No offence, but it doesn't 
  51. seem to me as an important issue.  Maybe MS should change their 
  52. implementation?)
  53.  
  54. > I don't remember about X offhand, but OS/2 Presentation Manager does not
  55. > require non-standard startup procedures.  The PM API is, as far as the
  56. > applications programmer is concerned, just another function library in a
  57. > DLL, and OS/2 PM programs start with `int main(int, char **)' just the same
  58. > as text-mode programs do.
  59.  
  60. I'm happy for OS/2 programmers. I really am! :-)  I still think that PM API
  61. makes programs unportable.  And the exact signature of the head function 
  62. helps a little.  I think that the biggest problems will be to map all PM
  63. procedures to their equvalents.  From my experience, sometimes you have 
  64. to redesign a few important parts of the program. And main() is a minor
  65. issue.
  66.  
  67. > And *this* is the issue at hand, not whether the APIs are portable.  Most
  68. > APIs appear as "just another function library" to the applications
  69. > programmer, and portability or otherwise of libraries is not an issue with
  70. > the C++ language itself.  The issue with the C++ language is that `main' is
  71. > the defined start procedure of *any* C++ program (sauf constructors of
  72. > objects at global namespace scope with static storage duration), and
  73. > Windows programs are *forced* to *not* use `main'.
  74.  
  75. See above.  You can do that with less-than-10-lines stub.  IMHO, C++ language
  76. doesn't care about the name of functions.  But run-time system do.  Standard
  77. tries to define the behavior of the active executable environment.
  78.  
  79. > Of course, as I've said before, the simple solution is to fix
  80. > [basic.start.main] to allow
  81. >     int main ( HINSTANCE, HINSTANCE, char *, int ) { /*...*/ }
  82. > as a legal definition of `main' (my proposal is for the implementation to
  83. > define a set of legal function types for the definition of `main', which at
  84. > minimum must contain `int main()' and `int main(int, char**)').  Then 
  85. > compiler vendors targetting DOS+Windows who wish to claim conformance can do
  86. > so by allowing their compilers to recognise the above function definition.
  87.  
  88. I'm not a pro in a standardization, but I think that this solution
  89. looks like a patch for MS Windows(TM).  What if totally graphical
  90. environment doesn't support any parameters or these parameters aren't a
  91. text?  This is a Unix heritage (and useful one :-) ).  What does
  92. HINSTANCE mean for ABCDOS?  What if all this four parameters don't make
  93. any sense at all for particular OS?  E.g., Win32 doesn't use the second
  94. HINSTANCE.  I don't speak about future OSes.
  95.  
  96. It seems to me that we can specify the order of execution but we don't have to
  97. dictate the real-world solutions.  To me "void main()" works just fine.  If 
  98. you want to obtain some shell-specific information or OS-specific data,
  99. use custom functions.  In simple cases "int main( int, const char** )"
  100. is suitable too.
  101.  
  102.  
  103. Eugene Lazutkin
  104. eugene@int.com
  105. ---
  106. [ To submit articles: try just posting with your news-reader.
  107.                       If that fails, use mailto:std-c++@ncar.ucar.edu
  108.   FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  109.   Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  110.   Comments? mailto:std-c++-request@ncar.ucar.edu.
  111. ]
  112.